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Foreword 



This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 

The 3GPP Confidentiality and Integrity Algorithms f 8 & f9 have been developed through the collaborative efforts of the 
European Telecommunications Standards Institute (ETSI), the Association of Radio Industries and Businesses (ARIB), 
the Telecommunications Technology Association (TTA), the Tl Committee. 

The f8 & f 9 Algorithms Specifications may be used only for the development and operation of 3G Mobile 
Communications and services. Every Beneficiary must sign a Restricted Usage Undertaking with the Custodian and 
demonstrate that he fulfills the approval criteria specified in the Restricted Usage Undertaking. 

Furthermore, Mitsubishi Electric Corporation holds essential patents on the Algorithms. The Beneficiary must get a 
separate IPR License Agreement from Mitsubishi Electronic Corporation Japan. 

For details of licensing procedures, contact ETSI, ARIB, TTA or Tl. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



This specification has been prepared by the 3GPP Task Force, and gives a detailed specification of the 3GPP 
confidentiality algorithm /5, and the 3GPP integrity algorithm/9. 

This document is the first of four, which between them form the entire specification of the 3GPP Confidentiality and 
Integrity Algorithms: 

- 3GPP TS 35.201: "3rd Generation Partnership Project; Technical Specification Group Services and 
System Aspects; 3G Security; Specification of the 3GPP ConfidentiaUty and Integrity Algorithms; 
Document \:f8 and/9 Specification". 

3GPP TS 35.202: "3rd Generation Partnership Project; Technical Specification Group Services and System 
Aspects; 3G Security; Specification of the 3GPP Confidentiality and Integrity Algorithms; Document 2: 
KASUMI Specification". 
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3GPP TS 35.203: "3rd Generation Partnership Project; Technical Specification Group Services and System 
Aspects; 3G Security; Specification of the 3GPP Confidentiality and Integrity Algorithms; Document 3: 
Implementors" Test Data". 

3GPP TS 35.204: "3rd Generation Partnership Project; Technical Specification Group Services and System 
Aspects; 3G Security; Specification of the 3GPP Confidentiality and Integrity Algorithms; Document 4: Design 
Conformance Test Data". 

The normative part of the specification of the f8 (confidentiality) and/9 (integrity) algorithms is in the main body of 
this document. The annexes to this document are purely informative. Annex 1 contains illustrations of functional 
elements of the algorithm, while Annex 2 contains an implementation program listing of the cryptographic algorithm 
specified in the main body of this document, written in the programming language C. 

The normative part of the specification of the block cipher (KASUMI) on which they are based is in the main body of 
Document 2. The annexes of that document, and Documents 3 and 4 above, are purely informative. 
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Scope 



This specification gives a detailed specification of the 3GPP confidentiality algorithm _/S, and the 3GPP integrity 
algorithm/9. 
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NORMATIVE SECTION 

This part of the document contains the normative specification of the Confidentiality and Integrity algorithms. 
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1 Outline of the normative part 

Section 1 introduces the algorithms and describes the notation used in the subsequent sections. 
Section 3 specifies the confidentiality algorithm /5. 
Section 4 specifies the integrity algorithm/9. 

1.1 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 33.102 version 3.2.0: "3rd Generation Partnership Project; Technical Specification 

Group Services and System Aspects; 3G Security; Security Architecture". 

[2] 3GPP TS 33.105 version 3.1.0: "3rd Generation Partnership Project; Technical Specification 

Group Services and System Aspects; 3G Security; Cryptographic Algorithm Requirements". 

[3] 3GPP TS 35.201: "3rd Generation Partnership Project; Technical Specification Group Services 

and System Aspects; 3G Security; Specification of the 3GPP Confidentiality and Integrity 
Algorithms; Document 1: f8 and f9 Specification". 

[4] 3GPP TS 35.202: "3rd Generation Partnership Project; Technical Specification Group Services 

and System Aspects; 3G Security; Specification of the 3GPP Confidentiality and Integrity 
Algorithms; Document 2: KASUMI Specification". 

[5] 3GPP TS 35.203: "3rd Generation Partnership Project; Technical Specification Group Services 

and System Aspects; 3G Security; Specification of the 3GPP Confidentiality and Integrity 
Algorithms; Document 3: Implementors" Test Data". 

[6] 3GPP TS 35.204: "3rd Generation Partnership Project; Technical Specification Group Services 

and System Aspects; 3G Security; Specification of the 3GPP Confidentiality and Integrity 
Algorithms; Document 4: Design Conformance Test Data". 

[7] ISO/IEC 9797-1 : 1999: "Information technology - Security techniques - Message Authentication 

Codes (MACs)". 
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Introductory information 



2.1 Introduction 

Within the security architecture of the 3GPP system there are two standardised algorithms: A confidentiality algorithm 
f8, and an integrity algorithm /9. These algorithms are fully specified here. Each of these algorithms is based on the 
KASUMI algorithm that is specified in a companion document[4]. KASUMI is a block cipher that produces a 64-bit 
output from a 64-bit input under the control of a 128-bit key. 

The confidentiality algorithm /5 is a stream cipher that is used to encrypt/decrypt blocks of data under a confidentiality 
key CK. The block of data may be between 1 and 20000 bits long. The algorithm uses KASUMI in a form of output- 
feedback mode as a keystream generator. 

The integrity algorithm/? computes a 32-bit MAC (Message Authentication Code) of a given input message using an 
integrity key IK. The approach adopted uses KASUMI in a form of CBC-MAC mode. 

2.2 Notation 

2.2.1 Radix 

We use the prefix Ox to indicate hexadecimal numbers. 

2.2.2 Conventions 

We use the assignment operator "=", as used in several programming languages. When we write 

<variable> = <expression> 
we mean that <variable> assumes the value that <expression> had before the assignment took place. For instance, 

x = X + y + 3 
means 

(new value of x) becomes (old value of x) + (old value of y) h- 3. 

2.2.3 Bit/Byte ordering 

All data variables in this specification are presented with the most significant bit (or byte) on the left hand side and the 
least significant bit (or byte) on the right hand side. Where a variable is broken down into a number of sub-strings, the 
left most (most significant) sub-string is numbered 0, the next most significant is numbered 1 and so on through to the 
least significant. 

For example an n-bit MESSAGE is subdivided into 64-bit substrings MBo,MBi...MBi so if we have a message: 

0x0 1 23456789ABCDEFFEDCB A98765432 1 08654538 1 AB594FC28786404C50A37 . . . 

we have: 

MB» = 0x0123456789ABCDEF 
MBi = 0xFEDCBA9876543210 
MB2 = 0x8654538 1AB594FC2 
MB3 = 0x8786404C50A37. . . 
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In binary this would be: 

000000010010001 10100010101 1001 1 1 10001001 1010101 1 1 1001 1011110111111111110. 

with MB» = 000000010010001 10100010101 1001 1 1 10001001 1010101 1 1 1001 101 1 1 101 1 1 1 
MBi = 1 1 1 1 1 1 101 101 1 100101 1 10101001 100001 1 101 1001010100001 1001000010000 
MB2 = 100001 10010101000101001 1 10000001 1010101 10101 100101001 1 1 1 1 1000010 
MB3 = 100001 1 1 100001 100100000001001 100010100001010001 10111... 



2.2.4 List of Symbols 



KASUMI[x]k 
X[i] 



The assignment operator. 

The bitwise exclusive-OR operation. 

The concatenation of the two operands. 

The output of the KASUMI algorithm applied to input value x 
using the key k. 



The i* bit of the variable X. (X = X[0] II X[l] II X[2] 



.). 



The i* block of the variable Y. (Y = Yoll Yj II Y2 II ....). 



2.3 List of Variables 

A, B are 64-bit registers that are used within the/5 and/9 functions to hold intermediate values. 

BEARER a 5-bit input to the/5 function. 

BLKCNT a 64-bit counter used in the/5 function. 

BLOCKS an integer variable indicating the number of successive applications of KASUMI that need to be 

performed, for both the/5 and/9 functions. 

CK a 128-bit confidentiality key. 

COUNT a 32-bit time variant input to both the/5 and/9 functions. 

DIRECTION a 1-bit input to both the/5 and/9 functions indicating the direction of transmission (uplink or 
downlink). 

FRESH a 32-bit random input to the/9 function. 

IBS the input bit stream to the/5 function. 

IK a 128-bit integrity key. 

KM a 128-bit constant that is used to modify a key. This is used in both the/5 and/9 functions. (It 

takes a different value in each function). 

KS[i] is the i* bit of keystream produced by the keystream generator. 

KSBi is the i* block of keystream produced by the keystream generator. Each block of keystream 

comprises 64 bits. 

LENGTH is an input to the/5 and/9 functions. It specifies the number of bits in the input bitstream. 

MAC-I is the 32-bit message authentication code (MAC) produced by the integrity function/9. 

MESSAGE is the input bitstream of LENGTH bits that is to be processed by the/9 function. 

OBS the output bit streams from the/5 function. 

PS is the input padded string processed by the/9 function. 

REGISTER is a 64-bit value that is used within the/5 function. 
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3.1 



Confidentiality algorithm f8 



Introduction 



The confidentiality algorithm _/S is a stream cipher that encrypts/decrypts blocks of data between 1 and 20000 bits in 
length. 



3.2 Inputs and Outputs 

The inputs to the algorithm are given in table 1, the output in table 2: 

Table 1: fS inputs 



Parameter 


Size (bits) 


Comment 


COUNT 


32 


Frame dependent input 
COUNT[0]...COUNT[31] 


BEARER 


5 


Bearer identity BEARER[0]...BEARER[4] 


DIRECTION 


1 


Direction of transmission DIRECTION[0] 


CK 


128 


Confidentiality key CK[0]....CK[127] 


LENGTH 


XI si 


The number of bits to be encrypted/decrypted 
(1-20000) 


IBS 


1-20000 


Input bit stream IBS[0]....IBS[LENGTH-1] 


Table 2: f8 output 


Parameter 


Size (bits) 


Comment 


OBS 


1-20000 


Output bit stream OBS[0]....OBS[LENGTH-1] 



3.3 Components and Architecture 



(See fig 1 Annex A) 

The keystream generator is based on the block cipher KASUMI that is specified in [4]. KASUMI is used in a form of 
output-feedback mode and generates the output keystream in multiples of 64-bits. 

The feedback data is modified by static data held in a 64-bit register A, and an (incrementing) 64-bit counter BLKCNT. 



3.4 



Initialisation 



In this section we define how the keystream generator is initialised with the key variables before the generation of 
keystream bits. 

We set the 64-bit register A to COUNT II BEARER II DIRECTION II 0...0 

(left justified with the right most 26 bits set to 0). 

i.e. A = COUNT[0]...COUNT[31] BEARER[0]...BEARER[4] DIRECTION[0] 0...0 

We set counter BLKCNT to zero. 

We set the key modifier KM to 0x55555555555555555555555555555555 

We set KSBo to zero. 

One operation of KASUMI is then applied to the register A, using a modified version of the confidentiality key. 

A = KASUMI[A]cKeKM 



In the sample C-code we treat LENGTH as a 32-bit integer. 
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3.5 Keystream Generation 



Once the keystream generator has been initialised in the manner defined in section 3.4, it is ready to be used to generate 
keystream bits. The plaintext/ciphertext to be encrypted/decrypted consists of LENGTH bits (1-20000) whilst the 
keystream generator produces keystream bits in multiples of 64 bits. Between and 63 of the least significant bits are 
discarded from the last block depending on the total number of bits required by LENGTH. 

So let BLOCKS be equal to (LENGTH/64) rounded up to the nearest integer. (For instance, if LENGTH = 128 then 
BLOCKS = 2; if LENGTH = 129 then BLOCKS = 3.) 

To generate each keystream block (KSB) we perform the following operation: 

For each integer n with 1 < n < BLOCKS we define: 

KSBn= KASUMI[ A 8 BLKCNT 8 KSB„.i]ck 

where BLKCNT = n-1 

The individual bits of the keystream are extracted from KSBi to KSBblocks in turn, most significant bit first, by 
applying the operation: 

For n = 1 to BLOCKS, and for each integer i with < i < 63 we define: 

KS[((n-l)*64)+i] = KSB„[i] 



3.6 Encryption/Decryption 



Encryption/decryption operations are identical and are performed by the exclusive-OR of the input data (IBS) with the 
generated keystream (KS). 

For each integer i with < i < LENGTH-1 we define: 

OBS[i] = IBS[i] e KS[/] 



Integrity algorithm f9 



4.1 Introduction 

The integrity algorithm/9 computes a Message Authentication Code (MAC) on an input message under an integrity key 
IK. There is no limitation on the input message length of the f9 algorithm. 

For ease of implementation the algorithm is based on the same block cipher (KASUMI) as is used by the confidentiality 
algorithm/S. 

4.2 Inputs and Outputs 

The inputs to the algorithm are given in table 3, the output in table 4: 
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Table 3: fd inputs 



Parameter 


Size (bits) 


Comment 


COUNT-I 


32 


Frame dependent input GOUNT-I[0]...GOUNT-I[31] 


FRESH 


32 


Random number FRESH[0]...FRESH[31] 


DIRECTION 


1 


Direction of transmission DIREGTION[0] 


IK 


128 


Integrity l<ey IK[0]...IK[127] 


LENGTH 


XI 92 


The number of bits to be "IVIAG"d 


MESSAGE 


LENGTH 


Input bit stream 


Table 4: f9 output 


Parameter 


Size (bits) 


Comment 


MAC-I 


32 


IVIessage authentication code MAC-I[0]...IVIAG-I[31] 



4.3 Components and Architecture 



(See fig 2 Annex A) 

The integrity function is based on the block cipher KASUMI that is specified in [4]. KASUMI is used in a chained 
mode to generate a 64-bit digest of the message input. Finally the leftmost 32-bits of the digest are taken as the output 
value MAC-I. 



4.4 Initialisation 



In this section we define how the integrity function is initialised with the key variables before the calculation 
commences. 

We set the working variables: A = 
and B = 

We set the key modifier KM to OxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

We concatenate COUNT, FRESH, MESSAGE and DIRECTION. We then append a single "1" bit, followed by 
between and 63 "0" bits so that the total length of the resulting string PS (padded string) is an integral multiple of 64 
bits, i.e.: 



COUNT[0]...COUNT[31] FRESH[0]...FRESH[31] MESSAGE[0]. 
MESSAGE[LENGTH-1] DIRECTION[0] 1 0* 



PS = 

Where indicates between and 63 "0" bits 



4.5 Calculation 

We split the padded string PS into 64-bit blocks PSi where: 

PS = PSoIIPSiIIPS2II....IIPSblocks-i 
We perform the following operations for each integer n with < n < BLOCKS-1: 

A = KASUMI[ A e PS„ ]iK 
B = B®A 

Finally we perform one more application of KASUMI using a modified form of the integrity key IK. 

B =KASUMI[B]iKeKM 
The 32-bit MAC-I comprises the left-most 32 bits of the result. 



' In the sample C-code we treat LENGTH as a 32-bit integer. 
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MAC-I = lefthalf[ B ] 

i.e. For each integer i with < / < 31 we define: 

MAC-I[i] = B[i]. 
Bits B[32]...B[63] are discarded. 
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INFORMATIVE SECTION 

This part of the document is purely informative and does not form part of the normative specification of KASUMI. 
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Annex 1 (informative): 

Figures of the fSand f9 Algorithms 



COUNT II BEARER II DIRECTION II 0...0 



CK©KM 




BLKCNT=0 -► 



BLKCNT=BLOCKS- !-►< 5 



-X3 



KASUMI 



T 
KS[0]...KS[63] 



CK 



KASUMI 



KS[64]...KS[127] 



KS[128]...KS[191] 



Figure 1 : f8 Keystream Generator 



Note: 



BLKCNT is specified as a 64-bit counter so there is no ambiguity in the expression 
A ® BLKCNT @ KSB„.i where all operands are of the same size. In a practical implementation where 
the key stream generator is required to produce no more than 51 14 bits (80 keystream blocks) only the 
least significant 7 bits of the counter need to be realised. 
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Figure 2: 19 Integrity function 
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Annex 2 (informative): 
Simulation Program Listing 

Header file 

/* 

* Kasumi.h 

* */ 

typedef unsigned char u8 
typedef unsigned short ul6 
typedef unsigned long u32 

/* a 64-bit structure to help with endian issues */ 

typedef union { 

u32 b32 [2] ; 

ul6 bl6 [4] ; 

u8 b8 [8] ; 
} REGISTER64; 

/* prototypes */ 

void KeySchedule { u8 *key ) ; 

void Kasumi { u8 *data ) ; 

u8 * f 9 { u8 *key, int count, int fresh, int dir,u8 *data,int length ) 

void f 8 { u8 *key, int count, int bearer, int dir,u8 *data,int length ) 

Function /S 

/* 

* F8 - Confidentiality Algorithm 



* A sample implementation of f8, the 3GPP Confidentiality algorithm. 
* 

* This has been coded for clarity, not necessarily for efficiency. 
* 

* This will compile and run correctly on both Intel {little endian) 

* and Sparc {big endian) machines. {Compilers used supported 32-bit ints) 
* 

* Version 1.0 05 November 1999 
* 

* */ 

#include "kasumi.h" 
#include <stdio.h> 

/* 

* f8{) 

* Given key, count, bearer, direction, data, 

* and bit length encrypt the bit stream 

* */ 

void f 8 { u8 *key, int count, int bearer, int dir, u8 *data, int length ) 

{ 

REGISTER64 A; /* the modifier */ 

REGISTER64 temp; /* The working register */ 

int i, n; 

u8 ModKey[16]; /* Modified key */ 

ul6 blkcnt; /* The block counter */ 

/* Start by building our global modifier */ 

temp.b32[0] = temp.b32[l] = 0; 
A.b32 [0] = A.b32 [1] = 0; 

/* initialise register in an endian correct manner*/ 

A.b8[0] = {u8) {count>>24) ; 

A.b8[l] = {u8) {count>>16) ; 

A.b8[2] = {u8) {count>>8) ; 

A.b8 [3] = {u8) {count) ; 
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A.b8[4] = {u8) {bearer<<3) ; 
A.b8 [4] 1= {u8) {dir<<2) ; 



/* Construct the modified key and then "kasumi" A */ 

f or { n=0; n<16; ++n ) 

ModKey[n] = {u8){key[n] ^ 0x55); 
KeySchedule { ModKey ) ; 

Kasumi { A.b8 ) ; /* First encryption to create modifier */ 

/* Final initialisation steps */ 

blkcnt = 0; 
KeySchedule { key ) ; 

/* Now run the block cipher */ 

while { length > ) 

{ 

/* First we calculate the next 64-bits of keystream */ 

/* XOR in A and BLKCNT to last value */ 

temp.b32[0] "=A.b32[0]; 
temp.b32[l] ^= A.b32[l]; 
temp.b8[7] ^= {u8) blkcnt; 
temp.b8[6] ^= {u8) {blkcnt>>8); 

/* KASUMI it to produce the next block of keystream */ 

Kasumi { temp.b8 ) ; 

/* Set <n> to the number of bytes of input data * 
* we have to modify. {=8 if length <= 64) */ 

if{ length >= 64 ) 

n = 8; 
else 

n = {length+7) /8; 

/* XOR the keystream with the input data stream */ 

f or { i=0; i<n; ++i ) 

*data++ ^= temp.b8[i]; 
length -= 64; /* done another 64 bits */ 
++blkcnt; /* increment BLKCNT */ 



end of 



Function /9 

/* 



F9 - Integrity Algorithm 



A sample implementation of f9, the 3GPP Integrity algorithm. 

This has been coded for clarity, not necessarily for efficiency. 

This will compile and run correctly on both Intel {little endian) 

and Sparc {big endian) machines. {Compilers used supported 32-bit ints) 



Version 1.1 05 September 2000 



iinclude "kasumi. h" 
#include <stdio.h> 

/* 

* f9{) 

* Given key, count, fresh, direction, data, 

* and message length, calculate the hash value 
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* */ 

u8 *f 9 { u8 *key, int count, int fresh, int dir, u8 *data, int length ) 

{ 

REGISTER64 A; /* Holds the CBC chained data */ 

REGISTER64 B ; /* Holds the XOR of all KASUMI outputs */ 

u8 FinalBit[8] = {0x80, 0x40, 0x20, 0x10, 8 , 4 , 2 , 1 } ; 

u8 ModKey [IS] ; 

static u8 mac_i [4] ; /* static memory for the result */ 

int i, n; 

/* Start by initialising the block cipher */ 

KeySchedule { key ) ; 

/* Next initialise the MAC chain. Make sure we * 

* have the data in the right byte order. * 

* <A> holds our chaining value. . . * 

* <B> is the running XOR of all KASUMI o/ps */ 

f or { n=0; n<4; ++n ) 

{ 

A.b8[n] = {u8) {count>> {24- {n*8) ) ) ; 
A.b8[n+4] = {u8) {fresh>> {24- {n*8) ) ) ; 

} 

Kasumi { A.b8 ) ; 
B.b32 [0] = A.b32 [0] ; 
B.b32 [1] = A.b32 [1] ; 

/* Now run the blocks until we reach the last block */ 

while { length >= 64 ) 

{ 

f or { n=0; n<8; ++n ) 

A.b8 [n] ^= *data++; 

Kasumi { A.b8 ) ; 

length -= 64; 

B.b32[0] ^= A.b32[0]; /* running XOR across */ 

B.b32[l] ^= A.b32[l]; /* the block outputs */ 
} 

/* Process whole bytes in the last block */ 

n = 0; 

while { length >=8 ) 

{ 

A.b8[n++] ^= *data++; 
length -= 8; 



/* Now add the direction bit to the input bit stream * 

* If length {which holds the # of data bits in the * 

* last byte) is non-zero we add it in, otherwise * 

* it has to start a new byte. */ 

if { length ) 

{ 

i = *data; 
if{ dir ) 

i 1= FinalBit [length] ; 

} 
else 

i = dir ? 0x8 : ; 

A.b8[n+ + ] ^= {u8)i; 

/* Now add in the final '1' bit. The problem here * 

* is if the message length happens to be n*64-l. * 

* If so we need to process this block and then * 

* create a new input block of 0x8000000000000000. */ 

if { {length==7) && {n==8 ) ) /* then we've filled the block */ 

{ 

Kasumi { A.b8 ) ; 

B.b32[0] ^= A.b32[0]; /* running XOR across */ 

B.b32[l] ^= A.b32[l]; /* the block outputs */ 

A.b8[0] ^= 0x80; /* toggle first bit */ 
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i = 0x8 0; 
n = 1; 

} 
else 

{ 

if { length == 7 ) /* we finished off the last byte */ 

A.b8[n] ^= 0x80; /* so start a new one */ 

else 

A.b8[n-1] ^= FinalBit [length+1] ; 



Kasumi { A.b8 ) ; 

B.b32[0] ^= A.b32[0]; /* running XOR across */ 

B.b32[l] ^= A.b32[l]; /* the block outputs */ 

/* Final step is to KASUMI what we have using the * 
* key XORd with OxAAAA */ 

f or { n=0; n<16; ++n ) 

ModKey[n] = {u8)*key++ " OxAA; 
KeySchedule { ModKey ) ; 
Kasumi { B.b8 ) ; 

/* We return the left-most 32-bits of the result */ 

for{ n=0; n<4; ++n ) 

mac_i [n] = B.b8[n]; 

return { mac i ) ; 



end of f 9 
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